アジャイルアライアンスの現評議員会によると、アジャイル手法は「キャズムを超えた」とのことです。これは、アジャイル手法がより広まっていることを意味すると私は考えます。これには利点がある一方で、問題も引き起こします。方法論や設計アプローチが流行すると、本質的な詳細よりも流行に注目する多くの人がそれを使い始めたり、教え始めたりします。これにより、アジャイルの名の下に行われたとされることの中には、運動の創設者の原則と正反対のものも含まれるという報告につながる可能性があります。

アジャイルソフトウェア開発は、要件分析、テスト、開発間のサイロの一部を解消しました。デプロイ、運用、保守は、ソフトウェア開発プロセスの残りの部分から同様に分離されている他のアクティビティです。DevOps ムーブメントは、これらのサイロを排除し、開発と運用間の協調を促進することを目的としています。

数年前、あるクライアントと話していたところ、彼が使用していたアジャイルアプローチについて気に入らない点を指摘されました。「プロジェクトのこの初期段階でこれほど苦労するのは、正しいとは思えません」。彼の反応とは逆に、私の考えでは、この初期の苦労は、アジャイル、あるいは実際にはあらゆる反復型開発プロセスの大きな利点の1つです。

エクストリームプログラミング（XP）は、主にKent Beckによって開発されたソフトウェア開発方法論です。XPは最初のアジャイル手法の1つであり、実際、スクラムが2000年代を通して主流になる前は、XPは90年代後半から2000年代初頭にかけて主流のアジャイル手法でした。多くの人々（私自身も含めて）は、XPがアジャイル手法への注目を集めた主要な触媒であり、アジャイル開発の出発点としてはスクラムよりも優れていると考えています。

多くの人は、アジャイルプロジェクトで固定価格契約を行うことはできないと考えています。アジャイルプロセスのポイントは将来を予測できないことなので、これは不合理な推測ではありません。しかし、これは固定価格のアジャイル契約を結べないという意味ではなく、固定スコープの契約を結べないという意味です。

最近、多くのプロジェクトで耳にする問題があります。それはこうです。

• 彼らはアジャイルプロセスを使用したいと考えており、スクラムを選択します。
• 彼らはスクラムの実践、そしておそらく原則も採用します。
• しばらくすると、コードベースが混乱しているため、進捗が遅くなります。

自分の仕事に責任感を持つならば、それをより良くすることに関心を持つでしょう。これには、自分の仕事のやり方について熟考し、新しい手法を試してみて、それが自分にとって改善をもたらすかどうかを確認することが含まれます。たとえ他の人が新しい手法を推奨したとしても、それが自分にとって有効かどうかを知る唯一の方法は、自分で試してみて、パフォーマンスが向上するかどうかを確認することです。

平均的な開発者はアジャイル手法を使用できますか？

よくある質問として、大規模なプロジェクトをアジャイル手法で実行できるかどうかがあります。結局のところ、多くのアジャイルアプローチは小規模なプロジェクト向けに設計されており、それらが抵抗する重量級の考え方は、より大規模なプロジェクトではより必要とされます。

成熟度モデルは、個人やグループの現在の有効性を評価し、パフォーマンスを向上させるために次に習得する必要がある能力を把握するのに役立つツールです。多くの分野で成熟度モデルは評判が悪くなっていますが、誤用される可能性はあっても、適切な運用では役立つ可能性があります。

ソフトウェア開発をスポンサーする人々は、通常、速度や本番環境へのデプロイ頻度などの開発指標にはあまり関心がありません。彼らは、手動作業の削減、より良い売上換算率、より高い顧客満足度など、ソフトウェアがもたらすビジネス上の利益、つまりビジネス成果をより重視します。成果志向のチームとは、ビジネス成果の提供を義務付けられ、そのための装備が整っているチームであり、成果を実現するために必要なすべてのアクティビティを実行できる人材がいます。対照的に、活動志向のチームは、そのための装備も義務付けもされていません。彼らは、成果を実現するために必要ないくつかの活動のうちの1つしか実行できません。

ソフトウェア開発で見られる事柄を説明するために新語を作る習慣があります。これはこの分野のライターの間では一般的な習慣であり、ソフトウェア開発はまだ多くの有用な専門用語を欠いているためです。専門用語を構築することの問題の1つは、用語が意味を失う可能性があることであり、意味の拡散のプロセスにおいて—これもまた私たちの専門用語への潜在的な追加です。

最近のコードオーナーシップの記事では、コードオーナーシップの問題について私がどのように考えているかを説明しました。私のソフトウェア開発の友人たちの多くはエクストリームプログラマーであり、集合的なコードオーナーシップを支持する傾向があります。しかし、このような慣習は絶対的なものではなく、常にローカルな考慮事項によって調整されるべきです。私の同僚の1人が、私の考えでは、慣習を変える必要がある場合の良い指標となる話を書いたメモを送ってくれました。（彼は自分のチームについて話しているので、匿名を希望しています。）

修・破・離とは、テクニックをどのように学ぶかについての考え方です。この名前は日本の武術（特に合気道）に由来しており、Alistair Cockburnは、ソフトウェア開発のテクニックや方法論を学ぶ上での考え方として導入しました。

時々、特定の専門分野を漸進的な方法で使用できるかどうかを疑問視する人がいます。「（セキュリティ|ユーザーインターフェース設計|データベース|国際化| *）をアジャイルプロジェクトで実行することはできません。なぜなら、この側面は事前に実行する必要があるからです。」

アジャイルプロジェクトで見られる一般的なことは、開発チームが単一のオープンテームルームに座っていることです。エクストリームプログラミングでは初期から提唱されており、第2版では主要なプラクティスの1つとして挙げられています。アジャイリストは、オープンテームルームを支持しており、チームのメンバー間の多くの非公式で深いコミュニケーションを促進します。

私のキャリアを通して見てきた一貫したテーマの1つは、ソフトウェア開発の性質と重要性です。数年前、見込み客が私たちのセールス担当者の一人に、「ソフトウェアは下水管のようなものです。信頼性を持って動作してくれれば、詳細は知りたくない」と言いました。これは、Nicholas CarrがIT Doesn't Matterで論じたアプローチの種類です。対照的に、私たちはITがビジネスにとってより明確な戦略的イネーブラーとなり、新しい市場参入や市場シェアの大幅な増加を可能にした多くの企業のために仕事をしてきました。では、ITは下水管のようなユーティリティなのでしょうか、それとも戦略的資産なのでしょうか？